This disclosure relates generally to interprocessor communication in a multiprocessor computing environment with transactional memory, and more specifically to communicating memory usage status between processors in such an environment.
The number of central processing unit (CPU) cores on a chip and the number of CPU cores connected to a shared memory continues to grow significantly to support growing workload capacity demand. The increasing number of CPUs cooperating to process the same workloads puts a significant burden on software scalability; for example, shared queues or data-structures protected by traditional semaphores become hot spots and lead to sub-linear n-way scaling curves. Traditionally this has been countered by implementing finer-grained locking in software, and with lower latency/higher bandwidth interconnects in hardware. Implementing fine-grained locking to improve software scalability can be very complicated and error-prone, and at today's CPU frequencies, the latencies of hardware interconnects are limited by the physical dimension of the chips and systems, and by the speed of light.
Implementations of hardware Transactional Memory (TM) have been introduced, wherein a group of instructions, called a transaction, operate atomically and in isolation (sometimes called “serializability”) on a data structure in memory. The transaction executes optimistically without obtaining a lock, but may need to abort and retry the transaction execution if an operation, of the executing transaction, on a memory location conflicts with another operation on the same memory location. Previously, software transactional memory implementations have been proposed to support software Transactional Memory (TM). However, hardware TM can provide improved performance aspects and ease of use over software TM.
U.S. Pat. No. 8,250,331, titled “Operating system virtual memory management for hardware transactional memory”, issued Aug. 21, 2012, teaches:                Operating system virtual memory management for hardware transactional memory. A method may be performed in a computing environment where an application running on a first hardware thread has been in a hardware transaction, with transactional memory hardware state in cache entries correlated by memory hardware when data is read from or written to data cache entries. The data cache entries are correlated to physical addresses in a first physical page mapped from a first virtual page in a virtual memory page table. The method includes an operating system deciding to unmap the first virtual page. As a result, the operating system removes the mapping of the first virtual page to the first physical page from the virtual memory page table. As a result, the operating system performs an action to discard transactional memory hardware state for at least the first physical page. Embodiments may further suspend hardware transactions in kernel mode. Embodiments may further perform soft page fault handling without aborting a hardware transaction, resuming the hardware transaction upon return to user mode, and even successfully committing the hardware transaction.        
U.S. Patent Application Publication No. US2012/0005530, titled “System and Method for Communication Between Concurrent Transactions Using Transaction Communicator Objects”, issued Jan. 5, 2012, teaches:                Transactional memory implementations may be extended to include special transaction communicator objects through which concurrent transactions can communicate. Changes by a first transaction to a communicator may be visible to concurrent transactions before the first transaction commits. Although isolation of transactions may be compromised by such communication, the effects of this compromise may be limited by tracking dependencies among transactions, and preventing any transaction from committing unless every transaction whose changes it has observed also commits. For example, mutually dependent or cyclically dependent transactions may commit or abort together. Transactions that do not communicate with each other may remain isolated. The system may provide a communicator-isolating transaction that ensures isolation even for accesses to communicators, which may be implemented using nesting transactions. True (e.g., read-after-write) dependencies, ordering (e.g., write-after-write) dependencies, and/or anti-dependencies (e.g., write-after-read dependencies) may be tracked, and a resulting dependency graph may be perused by the commit protocol.        